kexec: prevent deadlock on reentry to the crash path
authorAndrew Cooper <andrew.cooper3@citrix.com>
Wed, 27 Nov 2013 14:13:48 +0000 (15:13 +0100)
committerJan Beulich <jbeulich@suse.com>
Wed, 27 Nov 2013 14:13:48 +0000 (15:13 +0100)
commit470f58c159410b280627c2ea7798ea12ad93bd7c
tree78b8916f92982130815cba2e314ddcda5af803a3
parent5c447caaf49192c7b2c057ffbb565ce72aac666d
kexec: prevent deadlock on reentry to the crash path

In some cases, such as suffering a queued-invalidation timeout while
performing an iommu_crash_shutdown(), Xen can end up reentering the crash
path. Previously, this would result in a deadlock in one_cpu_only(), as the
test_and_set_bit() would fail.

The crash path is not reentrant, and even if it could be made to be so, it is
almost certain that we would fall over the same reentry condition again.

The new code can distinguish a reentry case from multiple cpus racing down the
crash path.  In the case that a reentry is detected, return back out to the
nested panic() call, which will maybe_reboot() on our behalf.  This requires a
bit of return plumbing back up to kexec_crash().

While fixing this deadlock, also fix up an minor niggle seen recently from a
XenServer crash report.  The report was from a Bank 8 MCE, which had managed
to crash on all cpus at once.  The result was a lot of stack traces with cpus
in kexec_common_shutdown(), which was infact the inlined version of
one_cpu_only().  The kexec crash path is not a hotpath, so we can easily
afford to prevent inlining for the sake of clarity in the stack traces.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: David Vrabel <david.vrabel@citrix.com>
xen/common/kexec.c